Business entities and consumers are storing an ever increasing amount of digitized data. For example, many commercial entities are in the process of digitizing their business records and/or other data. Similarly, web based service providers generally engage in transactions that are primarily digital in nature. Thus, techniques and mechanisms that facilitate efficient and cost effective storage of vast amounts of digital data are being implemented.
New data storage technologies are continuing to be developed and implemented by both commercial enterprises and consumers. Often, to help link remote (or even locally dispersed) locations that require access to stored data, and/or to ensure that such data remains available in the event of hardware, software, or even site failures (e.g., power outages, sabotage, natural disasters), entities have developed clustered networks that link disparate storage in a network available to a plurality of clients, for example.
As data storage requirements and/or management needs of a data management and storage network increase, such as for an enterprise, for example, components of the network may be replaced and/or upgraded. For example, an administrator may wish to replace two storage servers that can each store X amount of data with a single, more modern storage server that can store 2X data and has a faster data read time. In this example, data stored in the two storage servers will need to be transferred to the single replacement storage server prior to taking the two original storage servers out of the network.
However, data migration from a source location (e.g., the two storage servers being replaced) to a destination location can be complex and take a long-time. Further, access to the data being migrated is typically unavailable or at least limited during the transfer. Typically, data is transferred from the source location to the destination location on a block-level. That is, data is copied byte-by-byte, in memory blocks, from the source to the destination. The type of data, file-type, or way it is stored does not affect this type of data migration, as the data is merely copied in block form and written to the destination in block form. As an example, the source location may comprise virtual volumes (e.g., disparate memory blocks on physical drives that are emulated as a single volume of data to the storage network), which further comprises virtual drives (or pseudo-drives) (e.g., disparate memory blocks in the volume that are emulated as a single drive, such as a hard-drive, to the storage system). One example of a virtual drive is a Logical Unit Number (LUN) drive, which is identified by numbers that represent network memory locations of the data stored by the LUN.
Often, when replacing or upgrading a data storage unit, the replacement unit is different than those that are being replaced, and are therefore said to be “heterogeneous” (e.g., not the same). Copying data between storage volumes residing on heterogeneous (e.g., different types and/or manufacturers) storage systems is common when storage systems are being replaced and data is migrated to the replacements from those volumes being replaced. In an enterprise data storage and management environment the data migration typically involves large-scale block-level migration, which can be performed by connecting drive locations and transferring the data from the source to the destination over the connection, such as a storage network fabric (e.g., network connections).
Currently, techniques and/or systems utilize software and hardware that identifies the source and the destination, identifies a link between the two, and then semi-automatically transfers the data on a block-level. However, currently, the transfers do not identify a fastest path for data transfer, merely an available one, which can dramatically increase transfer times (e.g., by two to three time). Further, the current techniques and/or systems may not provide for automated error checking, where errors may occur during heterogeneous data transfers, for example. Additionally, if a data transfer error does occur during the migration, currently, the entire batch of data would need to be retransferred, which can lead to increased migration times.